1. The Field of the Invention
The present invention relates to organizing resources and, more particularly, to organizing resources into collections to facilitate more efficient and reliable resource access.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, Web browsing, and printing documents) include electronic communication between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
Due to the quantity and diversity of resources (e.g., devices and services) that are accessible via computer networks, a variety of different access mechanisms have been developed. Many access mechanisms utilize different protocols. For example, accessing Web pages on the World Wide Web (“WWW”) is typically facilitated using the HyperText Transfer Protocol (“HTTP”). On the other hand, accessing a file from a remote location can be facilitated using the File Transfer Protocol (“FTP”). At times, the same content can be transferred using different protocols at different times. For example, an electronic mail message can be transferred between mail servers using Simple Mail Transfer Protocol and then transferred to a client using the Internet Message Access Protocol (“IMAP”) or Post Office Protocol (“POP”).
However, before a protocol can be used to transfer or access a resource, a corresponding access mechanism must have some way to identify the resource that is to be accessed or transferred. For example, before a Web browser can use HTTP to access a Web page, the Web browser must have some way to identify the Web page that is to be accessed. Similarly, before a mail client can use IMAP or POP to receive an electronic mail message, the mail client must have some way to identify the mail server that is storing the electronic message. Accordingly, virtually all resource access mechanisms also include an identification mechanism that can be used to identify resources.
One identification mechanism includes utilizing a network address (e.g., an Internet Protocol (“IP”) address) to identify a corresponding computing device (e.g., a laptop, mail server, printer, PDA, etc.). Identifying computing devices by network address may be sufficient on smaller networks (e.g., Home Area Networks (“HANs”)) and/or on networks where network addresses change relatively infrequently. However, on distributed larger scale networks, using network addresses as an identification mechanism is often problematic. For example, due to the vast quantity of computing devices on the Internet, it may be difficult, if not impossible, for a user to remember IP addresses for every computing device the user may desire to access. Further, there is always some possibility that a provider will change the network address of a computing device or transfer ownership of the computing device to a different provider that controls different network addresses. Thus, subsequent attempts to access a computing device at a previously known network address can fail and there may be no way to easily determine a more recent network address.
Accordingly, other identification mechanisms represent network addresses as alphabetic strings that are typically easier to remember and provide some level of abstraction from network addresses. For example, Domain Name Services (“DNS”) can be used to represent IP addresses as alphabetic strings (e.g., corresponding to domain names). When an alphabetic string is used to identify a computing device, DNS checks a translation database to translate the alphabetic string to the corresponding IP address for the computing device. Further, when a new IP address is assigned to a computing device, the translation database can be updated such that a previously utilized alphabetic string identifying the computing device corresponds to the new IP address. Thus, DNS provides a level of abstraction that allows an IP address for a computing device to change without having to change the alphabetic string representing the computing device. Accordingly, if a provider changes an IP address for a computing device, the same alphabetic string can often be used to access the computing device.
However, since a computer system can be configured to simultaneous provide a number of different services, using DNS alone may not be sufficient to identify specific resources of a computing device. For example in some environments, using DNS as the sole identification mechanism, can make it difficult to differentiate between different services (e-mail, search functionality, etc.) offered by the same Web server. That is, identifying the Web server (e.g., by network address or alphabetic string) does not necessarily provide any indication of a specific service offered by the Web server. Thus, to access an electronic mail service of the Web server, an identification mechanism would need some way to differentiate the electronic mail service from other services of the Web server.
Uniform Resource Identifiers (“URIs”) are one mechanism that has been developed to more precisely identify resources. A URI can include a network address or alphabetic string identifying a computing device as well as an addition alpha-numeric string identifying a specific resource at the computing device. Uniform Resource Locators (“URLs”) refer to a subset of URIs that identify resources via representation of their primary access mechanics (e.g., their network location). Universal Resource Names (“URNs”) refer to a subset of URIs that are required to remain globally unique and persist even when a corresponding resource ceases to exist.
URLs are typically used for accessing resources on the Internet. For example, the URL “http://[domain name]/[alpha-numeric string]” can be used to identify a specific resource at a computing device on the WWW. URLs are also typically sub-divided into different schemes that represent different (often hierarchical) namespaces. For example, some of the different schemes used on the Internet include ftp, http, gopher, mailto, news, and telnet. Each of these schemes represents a different corresponding namespace respectively. This is beneficial as identification of resources can be scoped across the different namespaces and each scheme can have different syntax for identifying resources within its corresponding namespace. For example, the syntax for identifying resources in the http namespace and the syntax for identifying resources in the ftp namespace can differ.
Unfortunately, due at least in part to different schemes having different syntax, it is often difficult, if not impossible, to configure access to a resource such that the resource can be accessed from within multiple namespaces. That is, making a resource accessible from one namespace typically precludes the resource from being accessible from other namespaces. For example, the http scheme typically cannot be used to identify resources that have been configured for identification using the ftp scheme (and transfer using ftp). That is, a URL of the form http://[domain name]/[alpha-numeric string] typically cannot be used to identify a resource in the ftp namespace.
Further, typical resource identification mechanisms have limited querying capabilities. For example, one subset of URI share a common syntax for representing hierarchical relationships with a specified namespace. URIs of this subset can have the form <scheme>://<authority><path>?<query>, where the query portion is a string of information to be interpreted by the resource at <scheme>://<authority><path>. This facilitates the issuing of queries to a resource, such as, for example, to execute a search or discover resource capabilities.
However, typical resource identification mechanisms have limited, if any, functionality for utilizing a URI to query a namespace for resources contained in the namespace. URI syntax for some namespaces allow query functionality, but only at the lowest level within a namespace hierarchy (e.g., at leaf nodes). This results, at least in part, from the fact that existing namespace mechanisms do not view intermediate nodes as resources. Thus, a URI can be formulated to query for text files at a particular endpoint, such as, for example, URI representing a Web site for a specified corporation. However, it would be difficult, if not impossible, to formulate a URI to query the same namespace hierarchy for text files only from every domain ending in “.com”.
Further, existing searching mechanisms require that large quantities of resource information be cached. For example, most Internet search engines constantly scan the Internet for new URLs and cache the URLs locally. When a search (or query) is submitted to the search engine, the search engine searches the cached URLs. Thus, if a URL for a resource is not cached or the URL changes after caching, the URL or correct URL for a resource may not be returned in search results. Therefore systems, methods, computer program products that facilitate more efficient and reliable resource access would be advantageous.